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© Closed aloxolcolln opened this issue on Jan 11*3 comments 



alexeicolin commented on Jan 11 


Labels 


§s 


Package: ghc 7.8.2-3 (related llvm 3.5.0-3) 


None yet 


4- 


Architecture: armv7h 


Milestone 


111 


Device: Hardkemel Odroid U3 


No mtfestone 


What it isnl doing: A hello-world (and other) executables built with ghc. when run. print the error message 






pasted below and return a non-zero exit code. 


Assignee 




What it should be doing: A hello-world executable compiled with ghc should run correctly and return a zero 
exit code. 

Steps to reproduce. 


No one assigned 

2 participants 

W A 





S cat hello. hs 

main = putStrLn "hello" 

S ghc -o hello hello. hs 

[1 of 1] Compiling Main ( hello. hs, hello. o ) 

You are using a new version of LLVM that hasn't been tested yet! 
We will try though. . . 

Linking hello . . . 
i ./hello 

hello: schedule: re-entered unsafely. 

Perhaps a 'foreign import unsafe' should be 'safe'? 

S echo S? 

1 



When built with -threaded, hello docs not produce the same error, but it never returns. 

Link to vorboso ghc compllo log.. 

The log shows args to lie : -mattr=*v7, *vfp3, *di6 . in case this is related to ff 1 75. 

More details: 

This problem also manifests when trying to build GHC 7.8.4- 1 package from c 20 d 662 : an intermediate 
executable ghc-pwd fails in the above described way: 



configure: Building in- tree ghc-pwd 

You are using a new version of LLVM that hasn't Been tested yet! 

We will try though. . . 

checking for path to top of build tree... ghc-pwd: schedule: re-entered unsafely. 
Perhaps a 'foreign import unsafe' should be 'safe'? 
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configure: error: cannot determine current directory 
=> ERROR: A failure occurred in build(). 



Since it complains about LLVM being too new. I tried building an older one (v3.4-2 and v3.4.l -1 based on 
dates before the ghc 7.8.2 commit) as well as rebuilding the latest llvm 3.5.0-3 from Arch repo (which I 
have installed and is being used in the ghc build). All fail to build due to gcc getting stuck on compiling 
Function. cpp from the IR library (deterministically). The gcc command that never finishes (after 
outputting what looks like completed object code) Is the following. When this command is rerun manually 
outside of makepkg. same problem. 

acolin 407 90.0 13.9 305560 288776 pts/9 R* 17:14 13:23 /usr/lib/gcc/armv7l-unkno 




kmihelich commented on Jan 1 1 Owner 

ghc is very broken on ARM. The packages only remain to potentially help building in the future. 



0 A kmihelich closed this on Jan 1 1 




alexeicolln commented on Jan 11 

I gathered that much. The point of this report was to track the fact that ghc does not work. Yet. you just 
close the issue. Why not leave it open until it becomes invalid or is fixed one way or another? The next 
person who finds ghc not working would quickly find the report and not waste time scratching their head. 



Your policy is baffling. So far I've submitted a PR that was closed without a concrete reason and a bug 
report that was closed for no good reason. :'( 




alexeicolin commented on Jan 1 1 

I would either keep this open or keep the GHC package out of master branch for as long as it does not 
work at all. Development branches are a better place for things that might "potentially help building in the 
future". If a package is in master, and there are no open issues, then the user can't do better than assume 
that the package has been working in the past and should be more-or-less functional. You disagree? 



3 A kmihelich locked and fimited conversation to collaborators on Jan f 1 
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